La tinta de la variante de marca se deriva del relleno, no se fija - #20
Merged
Conversation
…fija `variant="default"` pintaba `bg-[var(--primary)] text-white`. El relleno es reasignable por la app que consume el paquete —Fovente lo ata al color que el cliente elige en Ajustes → Marca— y la tinta era una constante, así que sobre un relleno claro el rótulo desaparecía. Medido en el DOM vivo de Fovente (Chromium, ratio compuesto sobre el fondo real apilado): · tema oscuro, marca por defecto: blanco sobre #D98D7D = 2.61:1 ✗ AA · tema claro, marca amarilla: blanco sobre #F2C230 = 1.68:1 ✗ AA `--primary-foreground` ya existe en `styles/index.css` y vale `#ffffff` en los dos temas, así que para quien no lo reasigne (TimelyAI, Landing) esto no mueve un píxel: el par sigue siendo exactamente el mismo. Para quien sí lo reasigne, la tinta pasa a seguir al relleno. Las demás variantes conservan `text-white` a propósito: `--secondary`, `--destructive` y las de estado/canal son colores FIJOS del sistema, no de marca, y su par ya está verificado. El test lo afirma explícitamente para que un barrido de `text-white` no se lleve puesta esa distinción. `brand-ink-derives.test.tsx` se escribió contra la versión rota primero y falló ahí (2 de 3), con el control de no-vacuidad en verde. Nota: `ChatInput.test.tsx` falla en `main` desde antes de este cambio — reproducido sobre el árbol limpio. Ref: cofoundy/inbox-ai#617
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Button/Badgevariant="default"pintabanbg-[var(--primary)] text-white.El relleno es reasignable por la app que consume el paquete. Fovente ata
--primaryal color que el cliente elige en Ajustes → Marca, así que elrelleno era variable y la tinta encima constante: sobre un relleno claro el
rótulo desaparece.
Medido en el DOM vivo
Chromium real, ratio compuesto sobre el fondo apilado de verdad (no aritmética
de tokens), en la app de Fovente:
#FFFFFFsobre#D98D7D#FFFFFFsobre#F2C230#FFFFFFsobre#AC4A3AEl segundo no es hipotético: es el estado actual de cualquier tenant con una
marca clara, en toda acción primaria de la app.
El cambio
text-white→text-[var(--primary-foreground)], sólo en la variantedefaultdeButtonyBadge.Por qué esto NO mueve nada en TimelyAI ni en Landing
src/styles/index.cssya declara--primary-foreground: #ffffffen los dostemas (líneas 102 y 281). Quien no lo reasigne obtiene exactamente el mismo par
que antes — el cambio es un no-op visual. Quien sí lo reasigne (hoy sólo
Fovente) obtiene una tinta que sigue al relleno.
Lo que deliberadamente NO cambia
Las variantes
secondary,destructive, las de estado y las de canalconservan
text-white. Sus rellenos son colores fijos del sistema, no demarca, y su par ya estaba verificado. El test afirma esa mitad también, para
que un barrido futuro de
text-whiteno se lleve la distinción por delante.Test
src/__tests__/components/brand-ink-derives.test.tsx. Se corrió contra laversión rota primero: falló 2 de 3, con el control de no-vacuidad en verde. Un
test que nunca se vio en rojo no prueba nada.
Estado de la suite
npm test→ 503 passed / 1 failed. El fallo esChatInput.test.tsx(«shouldrender send button»), y es preexistente: se reproduce sobre
mainlimpio,sin este cambio.
Orden de aterrizaje
Este PR va primero. El de inbox-ai (que remapea
--primaryal color deltenant) depende de él: si aterriza al revés, los tenants con marca clara pasan
de tener el problema en 8 sitios parchados a tenerlo en todos.
Ref: cofoundy/inbox-ai#617